Thank you for proposing these changes. Regardless of the more substantial aspects, which also need to be reviwed, it would be difficult to remember the difference between pcap_dump1() and pcap_dump() (or pcap_dump2() if there is another variation in future). It would be easier with a name like pcap_dump_reliably(), pcap_dump_or_fail() or some such.

Thank you for proposing these changes. Regardless of the more substantial aspects, which also need to be reviwed, it would be difficult to remember the difference between pcap_dump1() and pcap_dump() (or pcap_dump2() if there is another variation in future). It would be easier with a name like pcap_dump_reliably(), pcap_dump_or_fail() or some such.

+1

pcap_dump_check_error()/pcap_close_check_error() is another alternative for the names.

@guyharris @infrastation any updates regarding the naming?

@guyharris @infrastation reminding you about this again.

Thank you for waiting. Naming consistency within a project usually works better than naming consistency between different projects, so it seems likely that before the new function names get set in stone they should be made to make the most sense to libpcap API users.

A good usage example for the new functions would be in tcpdump source code, this would also make it easier to confirm everything fits as expected. I have made a look at tcpdump.c with this in mind.

The first instance of pcap_dump_close() closes the file before opening the next one. Assuming a single file error should not abort the sequence, the only use for checking the return value of pcap_dump_close_GHPR1048() would be to skip the file compression and to print a warning message. In which case it would be useful to explain the error condition. Which makes me think it might be useful to mention in the man pages that when a new function returns PCAP_ERROR, the calling function can use errno to work the cause out.

The second instance looks similar.

The first instance of pcap_dump() knows it is writing to a file in a sequence, but it does not know how many more packets the current file is going to have, so the above thinking likely does not stand and the only reasonable thing to do on the first failed packet would be to fail right away with an error message. Which, again, would benefit from a meaningful error cause.

The second instance of pcap_dump() knows it is writing a single file, but for consistency and simplicity it seems best to treat all errors as hard errors.

The above changes in tcpdump would need to be conditional depending on HAVE_PCAP_DUMP_CLOSE_GHPR1048 and HAVE_PCAP_DUMP_GHPR1048 or some such, so tcpdump continues to compile with older libpcap versions. Thus the complication is not only in the proposed changes itself, but also in the incurred changes. So it would be best not to rush this before verifying everything.

Any name is fine with me, I only care about the functionality.

Yeah, but names accumulate, get in the way, and confuse people.
I'm trying to assemble some discussion about evolving the API.
Go ahead and work on any code you think makes sense to you, but don't get too attached to names yet.

Now that pull request #494 has been merged, this change needs to be rebased.

@infrastation I fixed the manpage and rebased!